-
Notifications
You must be signed in to change notification settings - Fork 835
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix storage range issue during snapsync #7624
Conversation
Signed-off-by: Karim Taam <[email protected]>
Not sure how feasible it would be but would love to get an automated test around this. I think it should go in the next release regardless as it has passed a lot of manual sync testing #7620 (comment) so is a clear improvement |
Signed-off-by: Karim Taam <[email protected]>
added a new tests and also modified the AccountHealingTrackingTest class in order to verify and match the new behavior |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
@matkt worth a changelog? |
don't think it is needed for this one |
Signed-off-by: Karim Taam <[email protected]> Co-authored-by: Simon Dudley <[email protected]>Signed-off-by: Chulhee lee <[email protected]>
PR description
Besu currently has a problem where, if it receives all storage slots at once without an accompanying proof, it correctly sets the end of the range to 0xFFF...FFFF. However, if all storage and a proof are received simultaneously, the logic mistakenly treats the end of the range as the last slot received rather than the expected end of the range. This discrepancy results in incomplete persistence of storage trie nodes.
Fixed Issue(s)
Thanks for sending a pull request! Have you done the following?
doc-change-required
label to this PR if updates are required.Locally, you can run these tests to catch failures early:
./gradlew build
./gradlew acceptanceTest
./gradlew integrationTest
./gradlew ethereum:referenceTests:referenceTests